1. Field of the Invention
The present invention relates generally to data processing environments and, more particularly, to an improved system and methodology for securing access to computer systems, networks, and related resources.
2. Description of the Background Art
The first computers were largely stand-alone units with no direct connection to other computers or computer networks. Data exchanges between computers were mainly accomplished by exchanging magnetic or optical media such as floppy disks. Over time, more and more computers were connected to each other using Local Area Networks or “LANs”. In both cases, maintaining security and controlling what information a computer user could access was relatively simple because the overall computing environment was limited and clearly defined.
With the ever-increasing popularity of the Internet, however, more and more computers are connected to larger networks. Providing access to vast stores of information, the Internet is typically accessed by users through Web “browsers” (e.g., Microsoft® Internet Explorer or Netscape Navigator) or other Internet applications. Browsers and other Internet applications include the ability to access a URL (Universal Resource Locator) or “Web” site. In the last several years, the Internet has become pervasive and is used not only by corporations, but also by a large number of small business and individual users for a wide range of purposes.
As more and more computers are now connected to the Internet, either directly (e.g., over a dial-up or broadband connection with an Internet Service Provider or “ISP”) or through a gateway between a LAN and the Internet, a whole new set of challenges face LAN administrators and individual users alike: these previously closed computing environments are now open to a worldwide network of computer systems. A particular set of challenges involves attacks by perpetrators (hackers) capable of damaging the local computer systems, misusing those systems, and/or stealing proprietary data and programs.
The software industry has, in response, introduced a number of products and technologies to address and minimize these threats, including “firewalls”, proxy servers, and similar technologies—all designed to keep malicious users (e.g., hackers) from penetrating a computer system or corporate network. Firewalls are applications that intercept the data traffic at the gateway to a Wide Area Network (“WAN”) and check the data packets (i.e., Internet Protocol packets or “IP packets”) being exchanged for suspicious or unwanted activities.
Another security measure that has been utilized by many users is to install an end point security (or personal firewall) product on a computer system to control traffic into and out of the system. An end point security product can regulate all traffic into and out of a particular computer. One such product is assignee's ZoneAlarm® product that is described in detail in U.S. Pat. No. 5,987,611, the disclosure of which is hereby incorporated by reference. For example, an end point security product may permit specific “trusted” applications to access the Internet while denying access to other applications on a user's computer. To a large extent, restricting access to “trusted” applications is an effective security method. However, despite the effectiveness of end point security products, issues remain in protecting computer systems against attack by malicious users and applications.
One particular problem that remains is how to secure access to certificates that exist on a user's machine and that are used for communicating and authenticating the user. A digital certificate (or “certificate”) is a secure electronic identity that certifies the identity of the holder. The most common use of a certificate is to verify that a user sending a message is who he or she claims to be, and to provide the receiver with the means to encode a reply. An individual wishing to send an encrypted message applies for a digital certificate from a Certificate Authority (CA). To create a certificate, the CA combines a user's public key with the user information (e.g., as defined by X.509), then signs the information with its private key. The digital certificate issued by the CA contains a variety of identification information, including a user name, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting and decrypting messages and digital signatures), and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Anyone receiving the certificate can verify its authenticity with the CA's public key. The recipient of an encrypted message uses the CA's public key to decode the digital certificate attached to the message, verifies it as issued by the CA, and then obtains the sender's public key and identification information held within the certificate. With this information, the recipient can send an encrypted reply. The authenticity of the CA's public key can be further verified via the chain of trust that exists within the PKI (public-key infrastructure), which is a popular mechanism for distributing keys in a secure way. A PKI may be installed on an enterprise network, or it may be available in a public environment.
X.509 is a widely used standard for defining digital certificates. X.509 defines a certificate format for binding public keys to X.500 distinguished path names. X.509 supports both secret-key (single-key) cryptography and public-key cryptography. X.509 version 3 defines the field contents of a certificate, which is a record of data that contains 11 major fields. The fields in the certificate define the issuing CA, the signing algorithms, how long the certificate is valid, and information about the owner of the certificate. The version 3 extension fields are useful for adding additional information into the certificate. This information can be customized to fit a particular issuer's own requirements. For example, a retailer could add unique customer information. These fields may provide access control information, which authorizes the holder of the certificate to access network or system resources. Thus, version 3 X.509 certificates can play a unique role in managing network security. For further description of X.509, see RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, by the Network Working Group, the disclosure of which is hereby incorporated by reference. A copy of RFC 2527 is available on the Internet from ietf.org (e.g., currently at www.ietf.org/rfc/rfc2527.txt).
With PCs and other computing devices today, a “certificate store” is provided (e.g., by the operating system) for use by applications. A certificate store is basically a repository for storing certificates that are used for communicating. For example, machines running Microsoft Windows have access to Windows' certificate store. Other available encryption applications/solutions (e.g., PGP, Open SSL, or the like) may include their own certificate store (i.e., beyond that provided by the operating system). An individual application itself may include its own certificate store. In Windows, the certificate store is subdivided into individual portions, such as a particular portion for a given user or for a given machine. In addition, certificates may be stored separately from the computer's general disk and memory storage in cryptographic “smart cards” or other storage devices, which prevent software on the computer from being able to retrieve the full private and public key pairs from the certificate.
Today, there is a need to balance cooperative enforcement (i.e., make sure a given client is compliant with an applicable security policy) with the existing protocols and applications. Consider, for instance, a user who is using a Web browser with SSL (Secure Sockets Layer), which is a protocol for secure network communications using a combination of public and secret key technology. The problem that presents itself is how to inspect the client PC to make sure it is compliant with a set of security policy requirements before allowing the client to log on to a corporate Web site. One approach to this problem is to download an ActiveX component to the client machine, where the ActiveX component has an engine that knows how to scan the client machine. (ActiveX refers to Microsoft's component technology based on Microsoft's Component Object Model (COM)). Upon concluding a successful scan, the ActiveX component may post a message back to the corporate Web server indicating that the client machine is compliant. In response to receiving such a message, the corporate Web server may grant access to that client machine. Typically, this means that the server grants access to a password page, where the individual user may authenticate himself or herself. In the foregoing approach, a two-stage process is employed. A component is first downloaded for scanning the client machine, followed by the user authenticating himself/herself. The Extensible Authentication Protocol (EAP) may be used to perform a similar but reversed approach where the user is first authenticated and then the client machine is scanned.
A monitoring protocol, such as Zone Labs' client monitoring protocol (CMP), may also be used to check the security attributes of the client device. (See, e.g., above mentioned commonly-owned, co-pending U.S. patent application Ser. No. 10/708,660. For example, a security module on a router may send a CMP challenge to a client device seeking access to a network. At that point, the router is not interested in authenticating the client but is instead interested in ensuring compliance to an applicable security policy. The CMP challenge comprises a UDP message having a fixed header and additional parameters that can be selected as options in order to check for particular attributes or conditions at the client device. Upon receipt of a challenge packet, a client security module formulates an appropriate response message using the same CMP protocol. The response message describes whether the client is currently compliant with the requirements provided in the CMP challenge. If the client is in compliance, the client is permitted to access the network. Otherwise, the client gets restricted access (or no access).
The basic problem underlying all of the foregoing approaches is that extra work must be layered on top of the existing protocols. In the case of CMP, an entirely different protocol must be employed, which has the additional disadvantage that it may not work through intervening NAT (Network Address Translation) boxes. EAP has the disadvantage that it only works with others who are also using EAP as the authentication system for their switches and routers; it does not work for long-distance, remote communication.
The ActiveX approach fares no better. The problem with using a downloaded ActiveX component is that again one is using an out-of-bandwidth channel that is not seamlessly integrated with existing protocols. Also, the approach assumes that the client machine's browser in fact supports ActiveX, or has been configured to allow execution of downloadable ActiveX components. Not all browsers support ActiveX, so the assumption is far from perfect. Further, the user may be employing a product that is not even a Web browser. Therefore, it is clear that one cannot assume that a client machine is going to be willing to download an ActiveX component for scanning that machine.
All told, the problem that remains is how to prevent a user from logging on to a site (e.g., corporate Web server) if that user does not pass the client compliance test, and do so in a manner that is seamlessly accommodated by existing protocols (e.g., SSL), and the application programs that implement those protocols (e.g., a web browser). The present invention provides a solution to this and other problems.